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Introduction 


Lorsque l’apprentissage en ligne en était à ses débuts, le modèle de référence pour le partage 
de contenu d’apprentissage, Sharable Content Object Reference Model (SCORM) en anglais a 
été mis en place pour permettre la communication entre des contenus d’apprentissage et un 
système de gestion des apprentissages (LMS 1 ). 

Le fait de se conformer à ce standard permet à des cours d’apprentissage en ligne et à des 
systèmes de gestion des apprentissages de parler un même langage. 

Cependant, les technologies utilisées pour concevoir des expériences d’apprentissage ont 
grandement évolué et SCORM ne facilite plus le travail des concepteurs, dans la mesure où il 
ne permet pas de suivre à la trace le parcours complet d’un apprenant. 

Aussi, de nos jours, la majeure partie des apprentissages a lieu lors d’activités non structurées; 
d’interactions sociales et à partir de plusieurs sources d’apprentissage informelles. En d’autres 
termes, l’apprentissage ne se fait pas uniquement au sein d’un cours en ligne. 

De plus, les apprenants utilisent au quotidien une multitude de sources d’information disponible 
à la demande pour apprendre (Yammer, Jive, Google chat, etc.) et ils s’inscrivent en grand 
nombre à des cours gratuits ouverts à tous (MOOC 2 ) des plus grandes universités (ex. : 
Coursera, Udacity, Khang Academy, Edx). Dans un tel paysage, l’apprentissage non structuré 
prend donc de plus en plus de place auprès des apprenants. 

Alors, plusieurs contraintes se posent avec SCORM, à savoir le fait qu’il n’est pas possible de 
suivre à la trace toutes ces expériences d’apprentissages des apprenants; de plus l’agrégation 
et l’analyse des données d’apprentissage restent déficientes. Il faudrait donc un nouveau 
standard qui permettrait une utilisation intelligente des données pour améliorer constamment 
les expériences d’apprentissage des apprenants. 


1 Learning Management System, en anglais 

2 Massive Open Online Cours (MOOC), en anglais 


Contexte 


De janvier à septembre 2012, l’équipe Tl de la SOFAD 3 a mené une étude exhaustive visant à 
sélectionner un nouvel environnement de conception et de production de ses cours en ligne. 
Cependant, au terme de cette démarche, il s’est avéré qu’aucun outil commercial disponible sur 
le marché ne rencontrait l’ensemble de ses besoins et exigences. 

La SOFAD a alors envisagé deux options : 

La première option a été de procéder au renouveau de son environnement auteur actuel ou 
comme seconde option, développer un nouveau système auteur « maison » à partir d’un 
logiciel à code ouvert "open source". Ce nouveau système se voulant facile d’utilisation par les 
équipes de production et flexible en termes de développement et d’extensions futures. 

Finalement, c’est la deuxième option qui a été retenue à savoir développer un nouveau 
système auteur « maison », car bien que le renouveau du wiki auteur 4 était possible, celui-ci 
resterait toujours une contrainte majeure en ce qui a trait à l’édition. En effet, il s'était avéré 
impossible d’améliorer l’éditeur d’édition compte tenu de l’architecture même de l’outil et du fait 
que celui-ci était fortement lié à la syntaxe de médiawiki. En revanche, notre nouveau système 
nous permettait d’améliorer l’éditeur des interactivités et d’être entièrement personnalisables et 
faciles d’utilisation. 


SOFAD/auteur une extension Wordpress 

Après une analyse minutieuse de plusieurs CMS 5 open source, notre choix s’est porté sur 
Wordpress. Cependant avant de recréer la roue, nous avons vérifié s’il n’existait pas une 
extension (plug-in) qui nous permettrait d’utiliser Wordpress comme un système auteur. 

De toutes les extensions que nous avons consultées (Namaste LMS, Sensei, WP Courseware, 
etc.), pratiquement aucune n’était vraiment conforme à un standard en particulier; les 
extensions qui annonçaient un aspect « auteur » l’étaient dans une infime mesure; aussi toutes 
les extensions consultées ne permettaient que d’utiliser Wordpress comme système de gestion 
des apprentissages LMS 6 (ex. : SCORM Cloud, LearnDash) et non comme un outil auteur a 
proprement parlé. C’est à cet instant que nous avons décidé de concevoir notre propre 
extension SOFAD/auteur. Pour plus d’information sur SOFAD/auteur et ce qu’est réellement un 
outil auteur, nous vous invitons à consulter la présentation suivante : cliquez ici. 

La SOFAD a développé une extension (plug-in) autour de l’environnement Wordpress pour lui 
permettre de concevoir et de produire ses cours en ligne. Cette extension (SOFAD/auteur) 
comprend un moteur d’interactivité lui permettant de produire plusieurs interactivités 
d’apprentissage et de les déployer au format SCORM 1 .2 vers plusieurs systèmes de 
gestion des apprentissages conforme à ce standard. (Ex : Moodle, Desire2Learn, 
Blackboard, etc.). 


3 Société de Formation à Distance des commissions scolaires du Québec 

4 Logiciel auteur actuel de la SOFAD basé sur médiawiki 

5 Content Management Système, système de gestion de contenu, en anglais 

6 Learning Management System (Système de gestion des apprentissages, en français) 
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Problématique 

Toutefois, certaines de nos interactivités d’apprentissage (ex : Voter et test à correction 
manuelle) ne sont pas réalisables avec la spécification SCORM. En effet, il n’est pas possible 
avec SCORM de collecter certaines données sur les expériences d’apprentissage des 
apprenants vu le mode de communication limité entre le contenu et le LMS. Aussi, avec 
SCORM, tous les apprentissages doivent être initialisés à partir d’un système de gestion des 
apprentissages (LMS); les contenus doivent résider sur le même domaine que le LMS; de plus, 
les contenus SCORM doivent obligatoirement fonctionner dans un navigateur (impossible sur 
des applications mobiles); de plus, il est impossible de suivre les activités des apprenants hors 
ligne et il est très facile pour un apprenant aguerri de pirater des contenus SCORM. Enfin, les 
supports utilisés de nos jours pour apprendre (plates-formes sociales, tablettes, livres 
numériques, téléphones intelligents, etc.) ont grandement changé ce qui n’a pas été le cas 
pour SCORM, puisque la spécification date de plus de dix ans! 


Expérience API (xAPI) 

Tin Can API aussi connu sous le nom d’expérience API ou xAPI est une nouvelle spécification 
pour les technologies d’apprentissage en ligne qui permet à des contenus d’apprentissage et à 
des systèmes de se parler de façon à recueillir et suivre à la trace tout type d’expérience 
d’apprentissage aussi bien en ligne que hors ligne Cet API capture les données dans un format 
consistent au sujet d’un apprenant ou d’un ensemble d’activités à partir de plusieurs outils 
technologiques. Plusieurs différents systèmes sont capables de communiquer de façon 
sécuritaire en capturant et en partagent ce flux d’activités en utilisant la syntaxe simpliste de 
xAPI. 

xAPI permet donc à tous ces systèmes de bâtir des expériences d’apprentissage et des outils 
qui parlent le même langage. Aussi, avec xAPI il est désormais possible d'agréger, de visualiser 
d’analyser les données d’apprentissage structurées et non structurées qui étaient auparavant 
non disponibles. Cette nouvelle spécification place l’apprenant au cœur du système comme le 
montre la figure 1 ci-dessous. 
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Figure 1 : l’apprenant au cœur de xAPI 


Le LRS 


xAPI nécessite l’utilisation d’un nouveau système, le LRS 7 . Le LRS fait partie intégrante de 
l’architecture de xAPI. C’est le lieu ou les données d’expériences d’apprentissage sont validées 
stockées en rendu disponible. Les données sont donc portables et facilement accessibles. 

Les expériences d’apprentissage sont stockées dans un « Entrepôt » de stockage des 
apprentissages, Learning Record Store (LRS) anglais. Ce LRS peut résider à l’intérieur ou à 
l’extérieur d’un LMS. 

xAPI n’exige pas à une expérience d’apprentissage de se faire sur un support particulier 
(Téléphone intelligent, ordinateur de bureau ou tablette); en ligne ou hors ligne et avec un 
système en particulier. 


7 LRS : Learning Record Store 
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Figure 2 : Le LRS dans l'architecture xAPI 
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La solution envisagée 



Fig. 3 : Architecture xAPI 


Une des solutions que nous avons envisagées à la SOFAD pour contourner les limitations de 
SCORM a été d’implanter le standard xAPI dans notre environnement auteur. L’implémentation 
de xAPI a nécessité l’utilisation d’un nouveau système, le LRS. Le LRS fait partie intégrante de 
l’architecture de xAPI, c’est le lieu où les données des différentes expériences d’apprentissage 
sont validées, stockées et rendues disponibles. À cet effet, une présentation détaillée sur le 
LRS est disponible ici . Aussi, nous avons retenu la solution à code ouvert Learning Locker 8 
pour les besoins de notre expérimentation étant donné qu’il nous semblait plus avancé en 
termes de développement que le LRS de ADL 9 . (Il s’agit des deux seules solutions à code 
ouvert à notre connaissance sur le marché actuellement, les autres étant des solutions 
propriétaires ou hébergées.) De plus, la conception d’un LRS allait au-delà du mandat de notre 
expérimentation et notre LRS se devait d’être public, c’est-à-dire non implanté au sein 
d’un LMS puisqu’il se pourrait que les autres institutions membres du GTN-Québec 


8 Learning Locker - LRS open source 

9 Advanced Distributed Learning - Secrétariat à la défense américaine. 
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envoient aussi leurs données vers ce LRS. À noter qu’un LRS peut résider à l’extérieur ou à 
l’intérieur d’un LMS. 


Learning Locker utilise le Framework PHP Laravel 10 , qui est un projet en source libre mature et 
actif. Le projet semble assez stable, mais un peu limité sur le plan des fonctionnalités (Plan de 
développement * 11 ). Il n'existe pas à l’heure actuelle de traduction française, mais il y a une 
ouverture dans ce sens de la part des initiateurs du projet, voir lien . Cependant, il n'existe pas 
encore de tests automatisés, ce qui peut laisser craindre que le projet, à mesure qu'il grandit, 
devienne instable, cependant, il est prévu de combler cette lacune 12 . 

Learning Locker utilise Composer 13 pour la gestion des dépendances, ce qui est une bonne 
pratique reconnue. Learning Locker utilise MongoDB 14 pour stocker les données, plutôt que 
l'habituel MySQL des applications PHP. C'est un choix très judicieux, car JSON 15 est la 
principale représentation des données pour MongoDB comme pour l'expérience API. Cette 
proximité entre le format des énoncés ( statements ) à stocker et le format de stockage en tant 
que tel simplifie grandement le travail du LRS. 


La démarche d’implémentation 


Notre expérimentation a porté sur deux interactivités qui ne sont pas réalisables avec la 
spécification SCORM. 

La première interactivité est un test à correction manuelle, dans lequel un apprenant répond à 
une série de questions qui lui sont posées et soumet ensuite ses réponses pour évaluation à un 
correcteur (Enseignant et/ou collègue de classe). Suite au dépôt de son test, le correcteur peut 
comparer les réponses aux corrigés fournis, les annoter et les noter en fonction du barème 
établi. Il peut aussi ajouter un commentaire global, s'il juge l’évaluation insuffisante; aussi, le 
correcteur peut demander à l'apprenant de reprendre son test. 

La seconde interactivité est un sujet de débat, accompagné d’une question sur laquelle 
l'apprenant doit se prononcer en votant. Dans cette interactivité de vote, une compilation de 
l’ensemble des votes des apprenants s’affiche à l’écran en même temps que la rétroaction à 
l’apprenant. 


Les cas d’utilisation 


Dans un premier temps, nous avons essayé de décrire les cas d’utilisation, c’est-à-dire identifier 
les différents systèmes concernés et préciser le rôle de chacun des acteurs, sachant que la 
spécification xAPI (Expérience API) encadre la communication entre plusieurs systèmes et 
implique plus ou moins directement plusieurs intervenants. Le diagramme 1 ci-dessous illustre 
les différents cas d’utilisation. 


10 http://laravel.com/ 

11 http://learninglocker.net/community/roadmap/ 

12 http://docs.learninglocker.net/docs/contributing#testing 

13 Https://getcomposer.org/ 

14 http://www.mongodb.org/ 

15 JavaScript Object Notation (JSON) 
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SOFAD/auteur (Logiciel 



Les rôles 

□ Créateur de contenu : individu voulant produire un contenu. 

□ Apprenant : individu qui interagit avec du contenu. 

□ Administrateur : individu ou organisation qui rendent disponible un contenu à un public 
quelconque. Par la suite, il agrège et interprète un ensemble de données résultantes de 
l’exploitation du contenu. 
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Les systèmes 


□ SOFAD/ auteur : outil de création de contenu. Il offre aux créateurs la possibilité de 
visualiser le contenu qu'ils créent, il n'est cependant pas conçu à priori pour héberger ce 
contenu et en gérer l'accès. 

□ Moodle LMS : système qui livre du contenu aux utilisateurs et qui gère les accès. 

□ SOFAD LRS : Système qui stocke sous forme d'énoncés l'entièreté des informations 
produites par l'interaction des utilisateurs avec le contenu. Il interagit avec le LMS et 
peut être dans ou en dehors du LMS. 

Les utilisations 

□ Rédiger le contenu : concevoir et intégrer un contenu composé de textes, de médias, 
d'interactivités, etc. 

□ Déployer du contenu conforme xAPI : obtenir d'un outil auteur qu'il produise un 
paquetage conforme au standard xAPI, c'est-à-dire qui envoie des énoncés significatifs 
à un LRS selon le protocole établi . 

□ Interagir avec du contenu : par exemple, naviguer à travers un hypertexte, passer un 
test, explorer une interactivité. Que ce soit les données nécessaires pour assurer un 
suivi, comme les réponses formulées par l'utilisateur, les données relatives à l'évaluation 
ou les données intéressantes sur le plan stratégique, elles sont conservées en 
produisant des énoncés qui sont envoyés à un LRS. Le contenu peut aussi récupérer 
des énoncés afin d'assurer une persistance entre les sessions de travail d'un utilisateur 
ou de permettre un partage entre utilisateurs. 

□ Produire et consulter des rapports : si on illustre ici ce cas d'utilisation comme prenant 
place dans le LRS, il n'en demeure pas moins que xAPI demeure vague sur le sujet en 
définissant le volet GET de son « Statement API », il offre plusieurs cas de figure 
possibles, tels que : 

. La production de rapports dans le LRS : le LRS est le dépôt des énoncés, ce qui amène 
à le considérer comme un endroit privilégié pour les analyser. 

. La production de rapports dans le LMS : le LMS offre souvent déjà une interface de 
gestion où il serait normal d'y ajouter la production de rapports sur les contenus xAPI qui y 
résident. 

. La production de rapport par une application spécialisée : il est possible d'accorder la 
permission d'émettre des requêtes au LRS à une autre application qui serait spécialisée dans 
la conception de rapports. 


Les diagrammes de séquences 

Dans un second temps, pour clarifier le déroulement chronologique typique d’utilisation d’une 
interactivité, nous avons produit un diagramme de séquence pour chacune des interactivités 
concernées. Par exemple, pour l’interactivité «voter», l’interaction entre les objets a lieu du 
côté de l’apprenant, en JavaScript, dans un cours déployé au format xAPI au sein d’un LMS. Le 
diagramme 2 ci-dessous, illustre le diagramme de séquence de l’interactivité « voter ». 
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Diagramme 2 : Diagramme de séquence de l’interactivité de vote 

Lorsqu’un apprenant se prononce sur une question en votant, les opérations du système se 
résument à deux grandes étapes : l’enregistrement de la réponse de l’apprenant et l’affichage à 
l’apprenant de l’ensemble des réponses obtenues jusqu’à présent. 

L’interactivité votée (Poil) adresse une demande d'enregistrement de la réponse de l’apprenant 
(answer) au système SOFAD/auteur (l’implémentation xAPI de l’interface SOFAD/auteur). 

SOFAD/auteur exécute cette requête en interagissant avec le xAPI Wrapper.js . Celui-ci envoie 
alors un énoncé (statement) au LRS. L’interactivité voter (Poil) demande ensuite toutes les 
réponses (getallAnswers) des apprenants à SOFAD/auteur. 

SOFAD/auteur interagit à nouveau avec le xAPI Wrapper pour répondre à cette requête. xAPI 
Wrapper obtient les énoncés du LRS par ajax. Une fois que l’interactivité voter (Poil) obtient les 
réponses, il affiche à l’écran les réponses à l’apprenant. Rappelons que xAPI Wrapper est un 
fichier JavaScript utilisé pour faciliter la communication avec le LRS. 
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(Voir en annexe le diagramme de séquence de l’interactivité « test à correction 
manuelle ») 

Le modèle du domaine 

Ensuite, nous avons défini les classes qui modélisent les entités ou les concepts présents dans 
le domaine de l’application, tout en gardant à l’esprit que les énoncés ( statements ) sont au 
centre de l’architecture xAPI. Le diagramme 3 ci-dessous est une représentation non 
exhaustive de l’ensemble des composantes possibles d’un énoncé, il illustre plutôt les 
composantes incontournables (celles que nous avons retenues de l’ensemble de la version 
1 .0.0 de la spécification xAPI) pour les besoins de nos interactivités. 





Diagramme 3 : Modèle du domaine 
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La formulation minimale d’un énoncé est la suivante « Acteur / Verbe / Objet / ». 



Fig 4 : Formulation d’un énoncé (statement) 

Un acteur peut être une personne ou un système. Alors qu’un objet est une activité quelconque. 
À noter qu’un objet peut jouer deux rôles dans un énoncé. 

□ Il peut être l’objet d’un énoncé, exemple « Jean a complété le test de mathématiques », 
test de mathématique est l’objet de l’énoncé. 

□ Il peut aussi être le parent de l’objet d’un énoncé, exemple dans l’énoncé « Jean a 
complété le test de mathématiques de son cours d’algèbre » « cours d’algèbre » étant le 
parent de l’objet « test de mathématiques ». De plus, le concept d’objet est assez large, 
allant d’une question à un cours complet. 

L’identification (id) des verbes, ainsi que l’id et le type des objets sont tous représentés par des 
IRI 16 et contrairement aux URI’s 17 , ils ne se limitent pas à un sous-ensemble de caractères 
ASCII. Dans le cas d’une ressource en ligne, l’id d’un objet est simplement l’adresse à partir de 
laquelle on peut accéder à la ressource en question. La figure ci-dessous est la représentation 
en JSON de l’énoncé de l’interactivité « voter » d’un apprenant. 


' internationalized resource identifier (IRI) 
uniform resource identifier (URI) 


17 




" act or"* 

"mbox": "mailto:pgagnon@sofad.qc.ca". 


"id": "http://adlnet.gov/expapi/verbs/answered", 



"object": { M 

"id": "http://dev4.sofad.qc.ca/www.demo/xapi-voter/package/page/mainpage.html", 
"objectType": "Activity”, 

"définition": { 

“type": "http://activitystrea.ms/schema/1.0/question" 



"context": { ^ 

"contextActivities": { 


"id": "http://dev4.sofad.qc.ca/www.demo/xapi-voter", 
"objectType": "Activity" 


"id": "2ecOfcb5-53c9-44d6-873d-3a921f5c3eb8", 
"authority": { 


"objectType": "Agent" 

"stored": "2014-08-18T18:53:09.824900+00:00", 
"timestamp": "2014-08-18T18:53:09.82490(H00:00" 




Fig 5 : Représentation JSON de l'énoncé du « voter » 


La requête faite au LRS pour afficher l’ensemble des réponses des apprenants à l’interactivité 
est composée des deux éléments suivants : le verbe et l’activité. 

En réponse à cette requête, le LRS répond en transmettant tous les énoncés incluant l’id du 
verbe et l’id de [activité correspondante. 

Diagramme des classes 

Finalement, nous avons identifié les principales classes impliquées dans le mécanisme de 
sauvegarde et restauration des données pertinentes à l’apprentissage de l’apprenant et à 
l’encadrement par un formateur. Les classes représentées sont implémentées en JavaScript et 
exécutées du côté client. Le diagramme 4 ci-dessous illustre ce concept. 
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Diagramme 4 : Diagramme des classes 

L’interface SOFAD/auteur (au milieu) existe afin de limiter autant que possible les dépendances 
entre les deux parties de la solution : nos sous-plugiciels (interactivités, questions et tests) et 
nos cibles de déploiement (xAPI, SCORM, eduSOFAD, etc). De plus, des ajouts sont à prévoir 
(nouveaux types de questions, nouvelles interactivités et cibles de déploiement) tout au long de 
la vie de l’environnement. 

L’interface SOFAD/auteur offre tous les services de persistance nécessaires à nos sous- 
plugiciels (dans le diagramme, les interactivités Poil (voter) et Assignment (Test à correction 
manuelle). Pour chaque cible de déploiement, il existe une implémentation de l’interface 
SOFAD/auteur. 

L’objectif est d’être en mesure de rendre compatibles de nouvelles cibles de déploiement sans 
intervenir dans les sous-plugiciels et, inversement, de développer de nouveaux sous-plugiciels 
qui soient immédiatement fonctionnels pour toutes les cibles de déploiement. 

— > Cliquez sur le lien suivant pour une démonstration complète de l’interactivité voter. 
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Les premiers avantages constatés 
La portabilité des données 

Les apprenants et les systèmes peuvent partager des données sur la « performance » de 
l'apprenant en dehors des LMS et avec d'autres applications. 

xAPI supporte une variété de types de contenu, les expériences d'apprentissage peuvent se 
produire partout et les conditions pour suivre à la trace ces activités d’apprentissage ne se 
limitent plus simplement au LMS. Le standard fournit une méthode de suivi des activités 
d’apprentissages et celles-ci peuvent avoir lieu sur de multiples supports (Tablettes, téléphones 
intelligents, etc.). De plus, l’apprentissage hors ligne (sans connexion réseau) est désormais 
possible. 

Approche centrée sur les apprenants 

xAPI est au centre de toutes les activités et expériences d’apprentissages rapportés, ce qui 
n’était pas le cas avec SCORM (approche plutôt centrée sur le cours); la spécification soutient 
les scénarios d'apprentissage en équipe et les scénarios d'évaluation avancés. Un concepteur 
peut décider du niveau de détail à rapporter en termes d’expérience d’apprentissage. 

Flexibilité des rapports, de l’analyse et du design 

L’introduction du nouveau standard xAPI permet aux organisations de rassembler, visualiser et 
analyser les données d’apprentissages structurés et non structurés qui n’étaient auparavant 
pas accessibles. 


Les enjeux et les défis à relever 


La sécurité et la confidentialité 

xAPI ne présume rien quant à l’authentification préalable d’un utilisateur et ne prévoit aucune 
méthode à cet effet. C’est l’activité qui est entièrement responsable de l’authentification et donc 
de l’identité de l’apprenant. Cette flexibilité se traduit par le fait que xAPI prévoit plusieurs 
façons d’identifier un apprenant (acteur) lors de l’envoi d’un énoncé : courriel ou URI OpenID 18 . 

Par ailleurs, les apprenants ne sont plus nécessairement connus à l’avance par le LRS comme 
c’est le cas dans un LMS avec SCORM, le LRS accepte un énoncé qui est correctement 
formulé même s’il s’agit d’un apprenant qu’il ne connaît pas. Lorsqu’un LMS consulte un LRS, il 
doit être en mesure de relier efficacement les identifiants des apprenants (acteurs) trouvés dans 
les énoncés du LRS avec ses propres comptes utilisateurs. 

Cela contraste avec SCORM API où l’apprenant doit être préalablement authentifié. 

Aussi. xAPIWrapper.js offre tout de même un modèle d’authentification très semblable à 
SCORM. Il propose deux façons d’indiquer à un contenu quel LRS utiliser et qui est l’acteur 
courant. Cependant, il est peu probable que tous les LMS compatibles xAPI adoptent cette 
façon de procéder. 


18 "OpenID Foundation website." 2005. < http://openid.net/ > 
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Dimension sémantique des verbes et des types d’activités 


Un élément important dans la formulation des énoncés est le choix et l'utilisation des verbes et 
des types d’activités ; les communautés de pratique ou certains ordres professionnels qui 
utilisent une terminologie qui leur est propre devront peut-être mettre en place, partager et 
maintenir des répertoires de verbes et de types d’activités avec leur définition exacte et leur 
contexte pour éviter toute ambiguïté dans l’interprétation des résultats et des données. 
L’industrie devra tenir à jour un répertoire central avec un vocabulaire commun pour s’assurer 
que les énoncés sont bien compris et conformes aux définitions convenues. Aussi, il est peu 
probable que chaque organisation rapporte volontairement vers ce répertoire central leurs 
verbes et types d’activités. Sans oublier la dimension linguistique; traduction (d’une langue à 
l’autre), d’une même expérience d’apprentissage avec des énoncés différents. Il y a lieu de 
s’inquiéter de la concordance entre les contenus, si chacun utilise des IRI différents pour 
identifier de mêmes activités. Cependant, une piste de solution semble se pointer à l’horizon 
avec le concept de « recipes ». 

Les outils de transmission des énoncés 

Les activités d’apprentissage n’ont plus seulement lieu à l’intérieur d’un LMS, mais bien de 
partout dans le monde réel. Il va donc falloir imaginer une multitude d’outils permettant de 
capturer ces expériences d’apprentissage. On voudra aussi s’assurer que les apprenants 
transmettent leurs énoncés vers le LRS lorsque ceux-ci sont hors d’un système formel 
d’apprentissage. 

Différentes applications et individus généreront des énoncées. Il faudra décider celles 
(applications et individus) que nous autorisons et celles que nous n’autorisons pas. Il faudra 
aussi décider si l’on accorde plus de droits et privilèges à une application ou un individu donné 
lorsque ceux -ci sont connus par le LMS. La gestion de tout cela reste floue. 

L’évolution et la conformité 

Avec le temps tous les systèmes vont générer une quantité énorme de données qui ne peuvent 
être réinitialisées. Les organisations devront choisir des LRS capables d’évoluer dans le temps 
pour rencontrer la demande de stockage et le traitement des données. Il faudra aussi assurer la 
conformité des nouvelles et anciennes versions de la spécification xAPI. 

xAPI permettant la granularité des données, il est possible de suivre des informations de façon 
plus détaillée et cela introduit de nouveaux défis, il faudra éviter de collecter des données 
inutiles. 
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Les recommandations 


Cette expérimentation a permis de démontrer comment ce nouveau standard pour les logiciels 
d’apprentissage en ligne facilite la communication entre les contenus d’apprentissage et les 
différents systèmes de façon à enregistrer et suivre à la trace tout type d’expériences 
d’apprentissage des apprenants y compris sur des appareils mobiles (iPad/tablettes) cela n'était 
pas possible autrefois avec le standard SCORM. 

xAPI est bien une alternative à SCORM, cependant, pour une implémentation réussie, nous 
suggérons fortement d’intégrer votre LRS au sein de votre LMS, pour une sécurité accrue. 
Contrairement à la croyance populaire, le LRS ne remplacera pas le LMS, le LRS doit être 
plutôt vu comme un complément au LMS. 

Adoptez le répertoire des verbes et des types d’activités de ADL afin d’éviter toute ambiguïté 
dans l’interprétation des énoncés et donc des données. Si vous devez créer de nouveaux 
verbes et types d’activités, n’hésitez pas à les soumettre à ADL pour approbation. Aussi, 
prévoyez avoir plusieurs LRS dans votre architecture pour ne pas avoir à mélanger vos 
données; car comme vous le savez, il n’est pas possible pour l’instant de réinitialiser les 
données générées. Enfin, optez pour un LRS installé (derrière votre pare-feu) ou hébergé, car 
les solutions dans le « nuage » reviennent chères en termes de coût/énoncé. 

En terminant, j’espère que cette expérimentation permettra de lever le doute et l’incertitude que 
vivent plusieurs institutions d’enseignement et organisations quant à l’adoption et l’utilisation de 
ce nouveau standard encore peu connu du monde de l'éducation. 
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Annexes 


La figure ci-dessous représente le diagramme de séquence de l’interactivité « test à correction 
manuelle) 


Si 1 



[apprena 


ms formateur] 

Indique qui est son formateur 

1 




Confirme l'ajout du formateur 





Rédige le travail 





Envoie le travail au formateur 





Confirme le partage du travail avec le formateur 




rapprenant 

Affiche le travail de l'apprenant 


Envoie l’évaluation à l’apprenant 
Confirme le partage de l’évaluation avec l'apprenant 


Affiche le travail de l’apprenant et l'évaluation 


Diagramme de séquence test à correction manuelle 
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Énoncés et documents du test à correction manuelle 

Cet exemple représente la situation où un apprenant a complété un test à correction manuelle 
et où son formateur l’a corrigé. 

Pour des fins de simplification de l’exemple ci-dessous, l’implémentation de notre interactivité 
“test à correction manuelle” limite l’interactivité à une seule question et, donc, l’apprenant n’y 
donne qu’une seule réponse. 
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Types d’entités : 


• State Document : stocke des données relatives à l’association entre un agent et une 
activité. 

• Statement : représente l’action d’un agent par rapport à un objet. 

Entités : 

• tuteurO, tuteurl : stocke qui est le formateur d’un apprenant pour un certain cours. 

• Apprenants : stocke qui sont les apprenants d’un formateur. 

• Tentatives : stocke l’identifiant de la tentative courante d’un apprenant pour une certaine 
activité notée. Il suffit d’inscrire une nouvelle tentative courante pour que l’apprenant 
amorce une nouvelle tentative. 

• Réponse : stocke la réponse donnée par un apprenant dans une activité notée, pour 
une certaine tentative. 

• Évaluation : stocke l’évaluation d’un formateur à une réponse donnée par un apprenant. 

Relations : 

• tuteurO et apprenants : ces deux documents associent un formateur et ses apprenants. 
xAPI ayant certaines limites quant aux requêtes qu’on peut formuler à un LRS, la 
redondance entre ces deux documents est nécessaire afin de pouvoir retrouver le 
formateur à partir de l’apprenant et vice-versa. 

• Tentative et tuteurO : ces documents ont lié par le fait qu’ils portent tous deux sur un 
même apprenant. 

• Tentative et réponse : la réponse donnée par l’apprenant pour une certaine activité et 
dont la tentative et la tentative courante sont celles qui sont considérées comme la 
réponse courante. 

• Apprenants et évaluation : l’acteur de l’énoncé évaluation est le formateur. 

• Réponse et évaluation : l’objet de l’évaluation, plutôt que d’être une activité, est l’énoncé 
réponse. De plus, ces deux énoncés réfèrent à la même tentative par leur propriété 
registration. 
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Glossaire 


Activity Provider 

Toute expérience ou activité d’apprentissage reçu par un LRS et pas 
seulement des contenus d’apprentissage en ligne 

Expérience API 

Un autre nom utilisé pour désigner le Tin Can API. 

Learning Record 
Store (LRS) 

Système qui stocke sous forme d'énoncés l'entièreté des informations 
produites par l'interaction des utilisateurs avec le contenu. 

Recipes 

Moyen standard d'exprimer un type particulier d'expérience et 
fournissant un langage commun pour éviter l'utilisation de différents 
mots signifiant la même chose. 

Registry 

Répertoires de verbes et des types d’activités avec leur définition exacte 
et leur contexte afin d’éviter toute ambiguïté dans l’interprétation des 
résultats et des données. 

Scorm parity level 

Implémentation de xAPI pour permettre minimalement au SGA 
d’importer, jouer et suivre des contenus xAPI 

Statement 

Un énoncé simple, consistant en <Acteur (apprenant)> <verb> <object>, 
avec <Résultat>, dans un 

<contexte> pour suivre un aspect d'une expérience d'apprentissage. Un 
ensemble de plusieurs énoncés peuvent être utilisés pour 
suivre l’ensemble des détails d’une expérience d'apprentissage. 

Tin Can API 

Une spécification visant les technologies d’apprentissage qui encadre la 
collecte de données liées aux expériences d’apprentissage d’une 
personne. 

xAPI 

Une abréviation d’Expérience API, lui-même étant un autre nom utilisé 
pour désigner le Tin Can API. 
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